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Foreword 



This Technical Specification has been produced by the 3GPP. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of this TS, it will be re-released by the TSG with an identifying 
change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

• 3 Indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document identifies identify and standardises the most important and strategic contexts in the physical 
architecture for the management of UMTS. It serves as a framework to help define a telecom management physical 
architecture for a planned UMTS and to adopt standards and provide products that are easy to integrate. 

This present document is applicable to all further Technical Specifications regarding the Telecom Management of 
UMTS. 



2 References 

2.1 Normative references 

[1] ITU-T Recommendation M.3010 (1996): "Principles for a telecommunications management 

network". 

[2] 3G TS 32.101 "3G Telecom Management principles and high level requirements" 

[3] ITU-T Recommendation Q.81 1 (1993), Lower layer protocol profiles for the Q3 interface. 

[4] ITU-T Recommendation X.200 (1994), Information technology - Open Systems Interconnection - 

Basic reference model: The basic model. 

[5] CCITT Recommendation M.3400 (1992), TMN management functions. 

[6] TeleManagement Forum, SMART TMN Technology Integration Map, GB909 (1998) 

2.2 Informative references 

[20] TMF GB9 1 0. Smart TMN Telecom Operations Map (Release 1.1) 

[21] TMF GB909. Smart TMN Technology Integration Map (Issue 1.1) 

3 Definitions, symbols and abbreviations 
3.1 Definitions 

For the purposes of the present document, the following definitions apply: 

Architecture: The organisational structure of a system or component, their relationships, and the principles and 
guidelines governing their design and evolution over time. 

Closed interfaces: Privately controlled system/subsystem boundary descriptions that are not disclosed to the public or 
are unique to a single supplier. 

De facto standard: A standard that is widely accepted and used but that lacks formal approval by a recognised 
standards organisation. 

Interface standard: A standard that specifies the physical or functional interface characteristics of systems, 
subsystems, equipment, assemblies, components, items or parts to permit interchangeability, interconnection, 
interoperability, compatibility, or communications. 

Interoperability: The ability of two or more systems or components to exchange data and use information. 

Intraoperability: The ability to interchange and use information, functions and services among components within a 

system. 
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IRP Information Model: An IRP Information Model consists of an IRP Information Service and a Resource Model 
(see below for definitions of IRP Information Service and Resource Model). 

IRP Information Service: An IRP Information Service describes the information flow and support objects for a certain 
functional area, e.g. the alarm information service in the fault management area. As an example of support objects, for 
the Alarm IRP there is the alarm record and alarm list. 

IRP Solution Set: An IRP Solution Set is a mapping of the IRP Information Service to one of several technologies 
(CORBA/IDL, SNMP/SMI, CMIP/GDMO, etc.). An IRP Information Service can be mapped to several different IRP 
Solution Sets. Different technology selections may be done for different IRPs. 

Management Infrastructure: The collection of systems (computers and telecommunications) a UMTS Organisation 
has in order to manage UMTS. 

Market Acceptance: Market acceptance means that an item has been accepted in the market as evidenced by annual 
sales, length of time available for sale, and after-sale support capability. 

Modular: Pertaining to the design concept in which interchangeable units are employed to create a functional end 
product. 

Module: An interchangeable item that contains components. In computer programming, a program unit that is discrete 
and identifiable with respect to compiling, combining with other modules, and loading is called a module. 

Open Specifications: Public specifications that are maintained by an open, public consensus process to accommodate 
new technologies over time and that are consistent with international standards. 

Open Standards: Widely accepted and supported standards set by recognised standards organisation or the commercial 
market place. These standards support interoperability, portability, and scalability and are equally available to the 
general public at no cost or with a moderate license fee. 

Open Systems Architecture (OSA): An architecture produced by an open systems approach and employing open 
systems specifications and standards to an appropriate level. 

Open Systems Strategy: An open systems strategy focuses on fielding superior telecom capability more quickly and 
more affordably by using multiple suppliers and commercially supported practices, products, specifications, and 
standards, which are selected based on performance, cost, industry acceptance, long term availability and supportability, 
and upgrade potential. 

Physical Architecture: A minimal set of rules governing the arrangement, interaction, and interdependence of the parts 
or elements whose purpose is to ensure that a conformant system satisfies a specified set of requirements. The physical 
architecture identifies the services, interfaces, standards, and their relationships. It provides the technical guidelines for 
implementation of systems upon which engineering specifications are based and common building blocks are built. 

Plug&play: Term for easy integration of HW/SW. 

Portability: The ease with which a system, component, data, or user can be transferred from one hardware or software 
environment to another. 

Proprietary Specifications: Specifications which are exclusively owned by a private individual or corporation under a 
trademark or patent, the use of which would require a license. 

Reference Model: A generally accepted abstract representation that allows users to focus on establishing definitions, 
building common understandings and identifying issues for resolution. For TMN Systems acquisitions, a reference 
model is necessary to establish a context for understanding how the disparate technologies and standards required to 
implement TMN relate to each other. A reference model provides a mechanism for identifying the key issues associated 
with applications portability, modularity, scalability and interoperability. Most importantly. Reference Models will aid 
in the evaluation and analysis of domain-specific architectures. 

Resource Model: A protocol independent model describing managed objects representing network resources, e.g. an 
RNC or NodeB. 

Scalability : The capability to adapt hardware or software to accommodate changing work loads. 

Specification: A document that prescribes, in a complete, precise, verifiable manner, the requirements, design, 
behaviour, or characteristics of a system or system component. 
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Standard: A document that establishes uniform engineering and technical requirements for processes, procedures, 
practices, and methods. Standards may also establish requirements for selection, application, and design criteria of 
material. 

Standards Based Architecture: An architecture based on an acceptable set of open standards governing the 
arrangement, interaction, and interdependence of the parts or elements that together may be used to form a TMN 
System, and whose purpose is to insure that a conformant system satisfies a specified set of requirements. 

System : Any organised assembly of resources and procedures united and regulated by interaction or interdependence 
to accomplish a set of specific functions. 

System Architecture: A description, including graphics, of systems and interconnections providing for or supporting 
management functions. The SA defines the physical connection, location, and identification of the key nodes, circuits, 
networks, platforms, etc., and specifies system and component performance parameters. It is constructed to satisfy 
Operational Architecture requirements per standards defined in the Physical Architecture. The SA shows how multiple 
systems within a subject area link and interoperate, and may describe the internal construction or operations of 
particular systems within the architecture. 

UMTS Organisation: A legal entity that is involved in the provisioning of UMTS. 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

BG Border Gateway 

BSC Base Station Controller 

BSS Base Station Subsystem 

BTS Base Transceiver Station 

CIM Common Information Model Specification (from DMTF) 

CMIP Common Management Information Protocol 

CMISE Common Management Information Service 

CORBA Common Object Request Broker Architecture 

FM Fault Management 

FT AM File Transfer, Access and Management 

FAV Firewall 

GGSN Gateway GPRS Support Node 

HLR Home Location Register 

HTTP HyperText Transfer Protocol 

IDL Interface Definition Language 

HOP Internet Inter-ORB Protocol 

IRP Integration Reference Point 

IWU Inter Working Unit 

MD Mediation Device 

MIB Management Information Base 

MIM Management Information Model 

MMI Man-Machine Interface 

MML Man-Machine Language 

MSC Mobile Service Switching Centre 

NE Network Element 

NSS Network Switching Subsystem 

NW Network 

OS Operations System 

OSF Operations System Functions 

PSTN Public Switched Telephone Network 

QA Q-Adapter 

OMG Object Management Group 

QoS Quality of Service 

SGSN Serving GPRS Support Node 

SLA Service Level Agreement 

SMI Structure of Management Information (RFC 1 155) 

SNMP Simple Network Management Protocol 

TLl Transaction Language 1 
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TM Telecom Management 

TMN Telecommunications Management Network as defined in ITU-T Recommendation M.3010 [1]. 

UML Unified Modelling Language 

VLR Visitor Location Register 

WBEM Web Based Element Management 

WS Workstation 

4 General 

4.1 UMTS 

4.1.1 UMTS Reference Model 

A Universal Mobile Telecommunications System is made of the following components: 

1 or more Access Networks, using different types of access techniques (GSM, UTRA, DECT, PSTN, ISDN, ...) 
of which at least one is UTRA; 

1 or more Core Networks; 

1 or more Intelligent Node Networks, service logic and mobility management, (IN, GSM ...); 

1 or more transmission networks (PDH, SDH etc) in various topologies (point-to-point, ring, point-to-multipoint 
etc) and physical means (radio, fiber, copper etc). 

The UMTS components have signalling mechanisms among them (V5, A, DSSl, INAP, MAP, #7, RSVP etc). 

From the service perspective, the UMTS is defined to offer: 

service support transparent to the location, access technique and core network, within the bearer capabilities 
available in one particular case; 

user to terminal and user to network interface (MMI) irrespective of the entities supporting the services required 
(VHE); 

- multimedia capabilities. 

4.1.2 UMTS Provisioning Entities 

UMTS 22.01 - "Service Aspects; Services Principles" identifies two major entities which cover the set of UMTS 
functionalities involved in the provision of the UMTS services to the user. These are: 

Home Environment. This entity holds the functionalities that enable a user to obtain UMTS services in a consistent 
manner regardless of the user's location or the terminal used. 

Serving Network. This entity provides the user with access to the services of the Home Environment 



4.1 .3 UMTS Management Infrastructure 



Every UMTS Organisation has it's own Management Infrastructure. Each Management Infrastructure will contain 
different functionality depending on the role played and the equipment used by that UMTS Entity. 

However the core management architecture of the UMTS Organisation is very similar. Every UMTS Organisation: 

- provides services to it's customers; 

needs an infrastructure to fulfil them (advertise, ordering, creation, provisioning, ...); 
assures them (Operation, Quality of Service, Trouble Reporting and Fixing, ...); 

- bills them (Rating, Discounting, ...). 
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Not every UMTS Organisation will implement the complete Management Architecture and related Processes. Some 
processes may be missing dependent on the role a particular UMTS Organisation is embodying. Processes not 
implemented by a particular UMTS Organisation are accessed via interconnections to other UMTS organisations which 
have implemented these processes (called X-interfaces in the TMN architecture). 

The Management architecture itself does not distinguish between external and internal interfaces. 

4.2 TMN 

TMN (Telecommunications Management Network), as defined in [1], provides: 

an architecture, made of OS (Operations Systems) and NEs (Network Elements), and the interfaces between 
them (Q3, within one Operator Domain and X, between different Operators) 

the methodology to define those interfaces 

other architectural tools such as LLA (Logical Layered Architecture) that help to further refine and define the 
Management Architecture of a given management area 

a number of generic and/or common management functions to be specialised/applied to various and specific 
TMN interfaces 

The UMTS Management Architecture is largely based on TMN, and will reuse those functions, methods and interfaces 
already defined (or being defined) that are suitable to the management needs of UMTS. However, the UMTS 
Management needs to explore the incorporation of other concepts (other management paradigms widely accepted and 
deployed) since: 

UMTS incorporates other technologies to which TMN is not applied fully 

UMTS faces new challenges that TMN does not address today 

It must be noted, that these concerns are applicable to other telecommunication areas as well as to UMTS, it is expected 
that the eventual evolution of TMN will cover this ground. Indeed, most of the above concepts are already being taken 
into account by TMN evolution (protocols and methodologies). 



5 General view of UMTS Management Physical 

architectures 

Telecom Management Architectures can vary greatly in scope and detail. The architecture for a large service provider, 
with a lot of existing legacy systems and applications, upon which many services are based, will be of high complexity. 
In contrast, the architectural needs of a start-up mobile operator, providing its services to a small group of valueadd 
Service Providers, will be much less and will probably focus on more short term needs. 

A mobile network operator has to manage many different types of networks as radio networks, exchanges, transmission 
networks, area networks , intelligent nodes and substantial amounts of computer hardware/software. This wide variety 
of network equipment must be obtained from a variety of equipment vendors. The nature of a mobile radio network will 
be heterogeneous and will present a number of operational difficulties for the service provider on enabling effective and 
efficient network management. 

The standardisation work for the management of UMTS has adopted the top-down approach and will from business 
needs identify functional and informational architectures. The physical architecture will have to meet these 
requirements and as there are many ways to build a UMTS it will vary greatly from one TMN solution to another. There 
will be many physical implementations as different entities will take different roles in a UMTS. 

It is obvious that it will not be meaningful or even possible to fully standardise a common telecom management 
physical architecture for UMTS. This document will identify and standardise the most important and strategic contexts 
and serve as a framework to help define a physical architecture for a planned UMTS. 
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6 Basic objectives for a UIVITS Physical Architecture 

The management of UMTS will put a lot of new requirements to the management systems compared to the second 
generation of Mobile telephony. Some of the challenging requirements affecting the physical architecture are 

To be capable of managing equipment supplied by different vendors. 

To enable TM automation in a more cost efficient way - TM optimised for maximum efficiency and 
effectiveness. 

To provide UMTS configuration capabilities that are flexible enough to allow rapid deployment of services. 

To report events and reactions in a common way in order to allow remote control. 

To allow interoperability between Network Operators/Service Providers for the exchange of 
management/charging information 

To be scaleable and applicable to both larger and small deployments. 

Accessibility to information 

To profit from advances and standards in IT and datacom industry. 

The second generation of mobile networks can from management point of view be characterised as the era of net 
element vendor dependent NE managers. The different OSs had very low interoperability with other systems and 
functional blocks could rarely be re-used. The Mobile Telecom Management Networks were far away from the TMN 
vision where one vendors OS should be able to manage other vendors net elements. 

For UMTS Management it is clearly stated the necessity of cost-effective solutions and better time to market focus. 
Interoperability, scaleability and re-use are keywords for the new generation of management systems. 

Many of the new requirements on the management of UMTS can only be solved by defining and establish a suitable 
physical architecture. Thou it is not possible to standardise the one single UMTS TM physical architecture, it is 
evidently so that the success of a telecom management network of a UMTS will heavily depend on critical physical 
architectural issues. This document will identify those architectural critical issues. 



7 TIVI Architectural aspects 



7.1 Architectural relationship 

The basic aspects of a TM architecture which can be considered when planning and designing a TM network are: 

The functional architecture 

The information architecture 

The physical architecture 

The management requirements from the business needs will be the base for the functional architecture which will 
describe the functions that have to be achieved. The information architecture defines what information that has to be 
provided so the functions defined in the functional architecture can be achieved. The physical architecture have to meet 
both the functional architecture and the information architectures. Other constraints from realty will also have impact to 
the physical architecture as cost, performance, legacy systems and all preferences any operator will have on a big 
capital investment as a TM network. 
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Figure 1: Architectural relationship 



7.2 



Architectural constraints 



Large software systems, such as a network management system, is a capital investment operators cannot afford to scrap 
every time its requirements change. Network operators are seeking cost-effective solutions to their short term needs. All 
these reality related issues are vital constraints that must be addressed in the definition of the architecture. 

The standardisation of UMTS will bring new and different services that will add new demands on network 
management. Every UMTS organisation will include different functionality depending on the role played and the 
equipment used by that UMTS entity. Regulation may force some of the roles that must be taken. The need to link 
systems across corporate boundaries will be a consequence of this. 

The rapid evolution of new services and technologies will also put requirements on the UMTS physical management 
architecture to accommodate market and technology trends. To future-proof investments and continuously be able to 
take advantage of new technologies are important constraints to the physical architecture. 

A UMTS TMN must also adopt an architecture that will achieve scalability and extensibility of systems and networks 
so the TMN can grow as the services expands over time. To start with a small TMN and easily be able to expand the 
TMN after new requirements will be important issues for most UMTS operators. 

The telecom management network will be just one part of the overall business of a company. System management, 
general security issues and development strategies can be the target for company policies. System architectures and 
technology choices, as well as the availability of off-the-shelf commercial systems and software components that fulfil 
the requirements established in this specification, maybe critical to an operator's implementation of the specified 
UMTS management architecture. 



7.3 Interoperability 



The new requirement on a UMTS TMN will imply a focus change from net element management towards management 
of information "information management". Network providers make use of different information in several different 
ways which also may vary from network to network and from time to time. Basic information as alarms is of course 
essential information for localising faults but may also be the key information to be able to set up a service with a 
service level agreement. 

Numerous of different interfaces can be identified in a UMTS network in the areas of network element management, 
network management and service management. The most important and complex of these interfaces will be 
standardised but many interfaces of less importance are unlikely to be fully standardised and will be up to the individual 
operator and vendor to develop. To adopt mainstream computing technologies, re-use widely used protocols, standards 
and an open system architecture will be essential to secure interworking between all physical entities in a UMTS. 

Low-cost and general access to management systems information will be needed. Obviously this is the critical issue 
and challenging task in the heterogeneous, distributed and complex network of a UMTS. 
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7.3.1 



Interfaces 



A UMTS will consist of many different types of components based on different types of technologies. There will be 
access-, core-, transmission- and intelligent node networks and many of the UMTS components have already been the 
target for Telecom Management standardisation at different levels. Many of these standards will be reused and the 
management domain of a UMTS will thereby consist of many TMNs. A architectural requirement for UMTS 
management must be to support distributed TMN's and TMN-interworking on peer to peer basis. 

The Telecom Management Architecture can vary greatly in scope and detail, because of scale of operation and that 
different organisations may take different roles in a UMTS (see chapter 5). The architecture of UMTS TMN's must 
provide a high degree of flexibility to meet the various topological conditions as the physical distribution and the 
number of NEs. Flexibility is also required to allow high degree of centralization of personnel and the administrative 
practices as well as allowing dispersion to administrative domains (see further chapter 10). The 3G Telecom 
Management architecture must be such that the NEs will operate in the same way, independently of the OS architecture. 

The following common NE Management Domains can be identified in a UMTS 
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Figure 2: Overview of the UIVITS Telecom IVIanagement Domains 

Itf-N between the NE OSFs and NM/SM OSFs. This could be used by the network- and service management systems to 
transfer management messages, notifications and service management requests via the NE OSF to the network 
elements. This interface must be open and the information models standardised. 
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Figure 3: Overview of the UIVITS Networit Element IVIanagement Domains and interfaces 

Itf-T between a terminal and a NE Manager. This interface will in some extent manage the 3G terminal and the 
USIM of the subscriber. Requirements of this interface are for further study. 

- Itf-B and Itf-R between UTRAN and a NE Manager. 

- Itf-Gl between GSM NSS and NE Manager. 

Itf-G2 between GSM BSS and NE Manager. This interface is standardised in GSM 12-series specifications. 

- Itf-G3 between GPRS NEs and a NE Manager. This interface is based on SNMP, GSM 12.15 (charging) and 
GSM 12.04 (performance management). 

Telecom management interfaces may be considered from two perspectives: 

the management information model 

the management information exchange 

The management information models will be standardised in other 3GPP documents but the management information 
exchange will be further described in this architectural standard. 

The management task will vary greatly between different network elements in a UMTS. Some NEs are of high 
complexity e.g. a RNC, while others e.g. a border gateway is of less complexity. Different application protocols can be 
chosen to best suite the management requirements of the different Network Elements and the technology used. 
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Application protocols can be categorised out of many capabilities as: 

- Functionality; 
Implementation complexity; 
Processor requirements; 
Cost efficiency; 

Market acceptance, availability of "off the shelf commercial systems and software". 

For each telecom management interface that will be standardised by 3GPP at least one of the accepted protocols will 
be recommended. Accepted application protocols ( e.g. CMIP,SNMP,CORBA HOP) are defined in [2] , Annex A. 

7.3.2 Open systems approach 

Even in the second generation of mobile radio networks the operators has to cope with heterogeneous environments in 
many different ways. No single vendor is likely to deliver all the management systems needed for a mobile operator. 

The many different types of network elements, some with very high management complexity as an exchange and some 
less complex as a repeater system, are generally supported with unique vendor specific management systems with very 
low interoperability. Duplicated TMN applications is an other obvious reality of this generation of management 
systems. This will be further discussed under Chapter 9 (TMN Applications). 

The new UMTS requirements call for open systems that can be supported by the marketplace, rather than being 
supported by a single (or limited) set of suppliers, due to the unique aspects of the design chosen. Open systems 
architectures are achieved by having the design focus on commonly used and widely supported interface standards. This 
should ensure costs and quality that are controlled by the forces of competition in the marketplace. 

The open systems approach is a technical and business strategy to: 

Choose commercially supported specifications and standards for selected system interfaces 

Build systems based on modular hardware and software design 

Selection of commercial specifications and standards in the Open systems approach should be based on: 

Those adopted by industry consensus based standards bodies or de facto standards (those successful in the 
market place) 

- Market research that evaluates the short and long term availability of products 
Tradeoffs of performance 

Supportability and upgrade potential within defined cost constraint 

Allowance for continued access to technological innovation supported by many customers and a broad industrial 
base 

7.3.3 Level of openness 

The level the interfaces conform to open standards are critical for the overall behaviour. A low level of openness will 
severely impact on long-term supportability, interoperability, development lead-time, life cycle cost and overall 
performance. 

Interfaces are expensive parts in a TMN and interfaces with low level of openness severely impacts on development 
lead-time for the introduction of any system, application component or service. Easy implementation (plug & play) is a 
requirement for UMTS TMN physical entities and requires a high the level of openness . 

7.3.4 Closed interfaces 

Many second generation mobile network physical management entities have vendor controlled system/subsystem 
boundary descriptions that are not disclosed to the public or are unique to this single supplier - closed interfaces. 
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In a UMTS network, such interfaces will not fulfil the basic requirements and can not be a part of a UMTS TMN. 

Closed interfaces can only be used as internal interfaces where no information what so ever has to be shared to other 
physical management entities. 

7.4 Data communication networks 

Within a TMN, the necessary physical connection (e.g. circuit-switched or packet-switched) may be offered by 
communication paths constructed with all kinds of network components, e.g. dedicated lines, packet-switched data 
network, ISDN, common channel signalling network, public-switched telephone network, local area networks, terminal 
controllers, etc. In the extreme case the communication path provides for full connectivity, i.e. each attached system can 
be physically connected to all others. 

The TMN should be designed such that it has the capability to interface with several types of communications paths, to 
ensure that a framework is provided which is flexible enough to allow the most efficient communications: 

- between NE and other elements within the TMN; 

- between WS and other elements within the TMN; 

- between elements within the TMN; 

- between TMNs; 

- between TMNs and enterprise. 

In this case the term efficiency relates to the cost, reliability and maintainability of the data transported. 

Costs are impacted by two aspects. The first is the actual cost to transport data across the network between the TMN 
and the NE. The second aspect is the design of the interface including the selection of the appropriate communications 
protocol. 

Whatever standardised protocol suite at the networking level that is capable of meeting the functional and operational 
requirements (including the network addressing aspects) of the Logical and Application Protocol levels of a given 
UMTS management interface, is a valid Networking Protocol for that interface. 

A number of requirements shall be met by the Networking Protocol, as follows: 

Capability to run over any bearer (leased lines, X.25, ATM, Frame Relay, ...) 

Support of existing transport protocols and their applications, such as OSI, TCP/IP family, etc. 

Widely available, cheap and reliable. 

The Internet Protocol (IP) is a Networking Protocol that ideally supports these requirements. IP also adds flexibility to 
how management connectivity is achieved when networks are rolled out, by offering various implementation choices. 
For instance, these may take the form of: 

Dedicated management intranets. 

Separation from or integration into an operator's enterprise network. 

Utilisation, in one way or another, of capacities of the public Internet and its applications or other resources. 



7.5 New technologies 



Meeting application requirements in the most affordable manner is together with development lead-time important 
issues identified in early UMTS management standardisation work. But the TMN functional, information and physical 
architectures must also keep pace with the introduction of new technologies, services and evolving network 
infrastructures. Technology is advancing so rapidly today that this must be a fundamental part of the physical 
architecture - to be able to easily adopt new important technologies. 

A UMTS will need to incorporate new successful technologies from the IT-world to which TMN standardisation is not 
fully applicable. Today distributed computing implementations have matured to a point where the goals of TMN can be 
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realised using commonly available technologies for a reasonable cost. 

Widely accepted open standards and new IT-technologies will be indispensable to fulfil the challenging managing 
requirements of UMTS. 

New technologies in the IT business as generic application components together with distributed processing technology 
are new important drivers upon application design of management systems. The possibility to purchase functional 
components from the open market are of great importance from many aspects as cost-efficiency and time-to-market. 



8 UMTS Management Physical architectures 

A UMTS Telecom Management Network will consist of many different management layers and many different 
building blocks. The complexity will vary greatly in detail because every organisation has different needs. The 
following chapter will identify the most critical architectural issues and compliance conditions for a given UMTS 
Management Interface. It should serve as fundamental requirements for any UMTS entity (network element or 
management system) being a part of a UMTS TMN. 



8.1 Compliance Conditions 



For a UMTS entity (Management System or NE) to be compliant to a given UMTS Management Interface, all the 
following conditions must be satisfied: 

1) It implements the management functionality following the Information Model and flows specified by the 
relevant 3GPP UMTS Management Interface Specifications applicable to that interface 

2) It provides at least one of the IRP Solution Sets (were available) related to the valid Application Protocols 
specified by 3GPP UMTS Application Protocols for that interface, [2] Annex C. 

3) It provides at least one standard networking protocol 

4) In case the entity does not offer the management interface on its own, a Q-Adaptor must be provided. This Q- 
Adaptor must be provided independently of any other UMTS NE and/or UMTS Management System. 

5) Support for Bulk Transfer Application Protocols (i.e. FT AM, ftp and tftp) [2]. 

8.2 Network elements management architecture 

The following figure demonstrates two possible options for management interface from the OS upper layers to NE. 
Option 1, provides access to the NE via element manager, and Option 2, provides a direct access. It is sufficient to 
provide one or the other. 
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Option 1 



Option 2 
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Fully standardized (3GPP Management Application Protocol + 3GPP Object Model) 
Open (3GPP Management Application Protocol + Vendor defined Object Model) 

Note: 3GPP Management Application Protocols are listed in 32.101 Annex A. 



Figure 4: Network Element IVIanagement Architecture 

For a UMTS entity (network element or management system) to be compliant to a given UMTS Management Interface 
the following conditions shall all be satisfied. 



Item 


Compliance conditions 


1 


Implements relevant 3GPP UMTS Management Information Model and flows 


2 


Application protocol ( e.g. CMIP,SNMP,GORBA MOP) defined in [2] , Annex A 
Implements relevant IRP Solution Sets, if available for that application protocol. 
(Defined in [2], Annex 0) 


3 


Internet Protocol (IP) 


4 


Lower protocol levels required by Item 1 ,2 and 3 
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Any other entity taking part in a UMTS, as an implementation choice, shall satisfy the following condition: 



Item 


Compliance conditions 


1 


Not standardised but open 



8.3 Network & Subnetwork Element Management Architecture 

( Example UMTS RNC / NodeB) 

An important special case of the network element management architecture is where one type of network element as the 
RNC will need management information for coordination of a subnetwork of other types of network elements as 
NodeB. 

This management information shared between the RNC and NodeB will not reach the operators and is not considered to 
be a part of the UMTS TMN. All other management information related to NodeB will transparently be transferred by 
the RNC towards the UMTS TMN. 
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Figure 5: Network and Subnetwork Management Architecture 

For a UMTS entity (network element, subnetwork element or management system) to be compliant to a given UMTS 
Management Interface the following conditions shall be satisfied. 
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Item 


Compliance conditions 


1 


Implements relevant 3GPP UMTS Management Information Model and flows 


2 


Application protocol ( e.g. CMIP,SNMP,CORBA MOP) defined in [2] , Annex A 
Implements relevant IRP Solution Sets, if available for that application protocol. 
(Defined in [2], Annex C) 


3 


Internet Protocol (IP) 


4 


Lower protocol levels required by Item 1 ,2 and 3 



8.4 Operations Systems interoperability architecture. 

Interoperability between operations systems is an important issue in a UMTS. Different organisations may take 
different roles in a UMTS. The need to share information across corporate boundaries will be a consequence of this. 

The heterogeneous, distributed and complex network of a UMTS will be a market for many different vendors. All 
operations systems has to interoperate and must be able to share information. This is a critical issue in the management 
of third generations systems. 
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Figure 6: Operations Systems interoperability Architecture 

For a Operations System to be UMTS TMN compliant the following conditions shall all be satisfied. 



Item 


Compliance conditions 


1 


Implements relevant 3GPP UMTS Management Information Model and flows 


2 


Application protocol ( e.g. CMIP,SNMP,CORBA MOP) defined in [2] , Annex A 
Implements relevant IRP Solution Sets, if available for that application protocol. 
(Defined in [2], Annex C) 


3 


Internet Protocol (IP) 


4 


Lower protocol levels required by Item 1 ,2 and 3 



8.5 Operations Systems intraoperability architecture 
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Figure 7: Operations Systems intraoperability Architecture 
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OS-Qintemai indicates an internal flow and should to be compliant with a given UMTS Management Interface satisfy the 
following conditions: 



Item 



Compliance conditions 



Implements relevant 3GPP UMTS Management Information Model and flows 



Application protocol ( e.g. CMIP,SNMP,CORBA MOP) defined in [2] , Annex A 
Implements relevant IRP Solution Sets, if available for that application protocol. 
(Defined in [2], Annex C) 



OS-QExternai indicates an external flow and shall to be compliant to a given UMTS Management Interface satisfy the 
following conditions: 



Item 


Compliance conditions 


1 


Implements relevant 3GPP UMTS Management Information Model and flows 


2 


Application protocol ( e.g. CMIP,SNMP,CORBA MOP) defined in [2] , Annex A 
Implements relevant IRP Solution Sets, if available for that application protocol. 
(Defined in [2], Annex C) 


3 


Internet Protocol (IP) 


4 


Lower protocol levels required by Item 1 ,2 and 3 



8.6 Business System interconnection architecture 

The business management layer has in the second generation systems a very low degree of standardisation. Operators 
have legacy systems or more IT influenced systems often adopted to every organisations different needs. Business 
systems is not a part of a UMTS TMN. 
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Figure 8: Business Systems interconnection architecture 

OS-QExterai Indicates an external flow and shall to be compliant to a given UMTS Management Interface satisfy the 
following conditions: 



Item 


Compliance conditions 


1 


Implements relevant 3GPP UMTS Management Information Model and flows 


2 


Application protocol ( e.g. CMIP,SNMP,CORBA MOP) defined in [2] , Annex A 
Implements relevant IRP Solution Sets, if available for that application protocol. 
(Defined in [2], Annex C) 


3 


Internet Protocol (IP) 


4 


Lower protocol levels required by Item 1 ,2 and 3 
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IFx indicates an external flow and shall to be compliant to a given UMTS Management Interface satisfy the following 
condition: 



Item 


Compliance conditions 


1 


Not standardised but open 



TMN applications 



Telecom management applications can be implemented in many different ways depending on constraints presented in 
previous sections of this technical specification. Consistent operational processes are required for the management of 
the network irrespective of vendor equipment. A mobile operator can because of the very heterogeneous nature of their 
networks easily end of with dozens of duplicated applications for e g alarm surveillance. Most vendors of network 
equipment offers dedicated netelement managers and the ones not built with an open system approach will severely 
limit the possibility to report and manage the network in a consistent way. 

Network element vendors with closed and unique netelement managers or operations systems with closed interfaces or 
interfaces with low level off openness will not fulfil the basic requirements as a part of a UMTS. It will not be possible 
to design and build the telecom management network to support the operational processes as required. Such physical 
entities are not under consideration in this technical specification. 

Many TM application functions can be identified as generic functions used by all major types of telecom equipment. 
Alarm surveillance applications and performance analysing applications are generic necessities to manage most network 
elements. Security and system management applications are also common to many TM components and may be the 
scope for overall business policies. 

To identify and specify the design criteria that will allow re-usable application components to be developed across 
multiple telecom business scenarios are important issues to fulfil the basic UMTS Managenent requirement "To 
minimise the costs of managing a UMTS network such that it is a small component of the overall operating cost". 

The implication of the top down approach in the standardising work of UMTS is that consistent operational 
management processes are required irrespective of vendor equipment. 

Generic management applications is required to facilitate: 

Reduced management application development costs 

Simplification of operational processes and associated reduction in costs 

Reduced time to deploy new services as management systems already exist 

Consistent representation of basic information 
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Figure 9: Unique NE fault management 

Figure 9 represents a very common situation in the management of second generation of mobile networks. Different 
vendors supplied their network elements with unique netelement managers. The interfaces were mostly proprietary or 
unique. The information models for generic information as alarms were rarely standardised. All together the 
consequence for the operators became very complex. Similar information at many levels, repeated acknowledge of 
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alarms, inconsistent representation of similar information are a few of all the difficulties the operators had to cope with. 

Some of the more severe implication of this situation is the difficulty to add more intelligence into the applications to 
better support the processes of the network providers. The operators who tried to brake up this situation had to put in a 
lot of effort into software development and proprietary interfaces. The marketplace did not support the needs of the 
operators. 
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Figure 10: Generic fault management 

Figure 10 indicates the situation were the telecom management process alarm surveillance is supported by a generic 
application for fault management. A common information model and accessibility to all related information will make 
it possible to add more intelligence to the management systems and to better support the management task. 

TMN application functions as billing information collection or configuration management of a specialised network 
element are examples of application that can be identified as unique applications. Even these applications will need to 
interoperate with other applications and will also need the open system approach to be a part of a UMTS TMN. With a 
network with many different types of network elements a common graphical user interface as a webb browser for 
configuration management applications could be an important issue to create consistent operational processes. 

The complexity and heterogeneous nature of UMTS calls for easy integration (plug&play) of HW/SW. 



10 Integration Reference Points 
10.1 General 

Relating to the OSI functional areas "FCAPS", IRPs are here introduced addressing parts of "FCPS" - Fault, 
Configuration, Performance, and Security management. Comparing with TMF TOM (Telecom Operations Map), the 
introduced IRPs address process interfaces at the EML-NML (Element Management Layer - Network Management 
Layer) boundary. In 3GPP/SA5 context, this can also be applied to the "N-interface" between EM-NM and NE-NM. 

The three cornerstones of the IRP concept are: 

- Top-down, process-driven modeling approach 

The purpose of each IRP is automation of one specific task, related to TMF TOM. This allows taking a "one step 
at a time" approach with a focus on the most important tasks. 

- Protocol-independent modeling 

Each IRP consists of a protocol-independent model (the IRP information model) and several protocol-dependent 
models (IRP solution sets). 

- Standard based protocol dependent modeling 

Models in different IRP solution sets (CMIP, SNMP, WBEM, ...) will be different as existing standard models of 
the corresponding protocol environment need to be considered. The means that solution sets largely need to be 
"handcrafted". 



10.2 Integration levels 



Virtually all types of telecom/datacom networks comprise many different technologies purchased from several different 
vendors. This implies that the corresponding management solution need to be built by integrating product-specific 
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applications from different vendors with a number of generic applications that each provide some aspect of multi- 
vendor and/or multi-technology support. A complete management solution is thus composed of several independent 
applications. 

The following levels of integration are defined: 

Screen Integration: Each application provides its own specific graphical user interface (GUI) that need to be 
accessible from a single, unified screen (a common desktop). A seamless integration between the various GUIs 
is then required. Screen Integration will not be standardised in this Technical Specification. 

- Application Integration: Applications need to interwork, on a machine-machine basis, in order to automate 
various end-to-end processes of a communication provider. 

10.2.1 Application integration 

Interfaces related to application integration can be divided in the following three categories: 

High-level generic interfaces between generic applications on the network and service management layers. The 
same approach and concepts apply for these as the next category: 

- High-level (technology-independent to the extent possible) interfaces between product-specific and generic 
applications are needed in order to automate and streamline frequently occurring tasks applicable to several types 
of network elements. A top-down approach shall be taken when defining these interfaces, where the main input 
is (1) business processes of a communication provider, and (2) the types of generic applications that are used to 
implement the process support. The interfaces need to be stable, open and (preferably) standardised. These IRPs 
are discussed below under the heading Network Infrastructure IRPs. 

- Detailed (product-specific) interfaces between product-specific applications and the corresponding network 
elements are of course also needed. These interfaces are defined using the traditional bottom-up approach, where 
the actual network infrastructure is modelled. This is the traditional TMN approach to element management. The 
management information in these interfaces is not further discussed in this document, as it is internal to a 
specific development organisation and does not need to be open. In fact, by publishing the management 
information in these interfaces, too much of the internal design may be revealed and it may become impossible 
to later enhance the systems that are using the interfaces. The management services (operations and 
notifications) and protocol shall however be open and standardised as long as they are independent of the MIM 
describing the managed NEs/NRs. 

10.3 Network infrastructure IRPs 

When providing integrated management solutions for multi-vendor networks, there is a strong requirement that the NEs 
and the management solutions that go together with them are systems integrable. It is here proposed that the telecom 
vendors provide a set of Network Infrastructure IRPs. 

It should be noted that these IRPs could be provided by either the NE, or the Network Element Manager (EM) or Sub- 
Network Manager (SNM) that goes together with the type of NE. There is actually not a clear distinction any more 
between NE and element management applications, mainly due to the increased processing capacity of the equipment 
platforms. Embedded Element Managers providing a web user interface is a common example of that. 

These IRPs are introduced to ensure interoperability between product-specific applications (PSA) and the types of 
generic applications shown in the figure below. These IRPs are considered to cover the most basic needs of task 
automation. 
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Figure 11: IRPs for application integration 

The following gives examples of some basic IRPs: 

The most basic need of a fault management (FM) application is to support alarm surveillance. Product-specific 
applications need to supply an Alarm IRP to forward alarms from all kinds of NEs and equipment to the FM 
application. 

A Configuration Service IRP is needed for retrieval of the configuration and status of the corresponding network 
elements. It can also be used by inventory management applications, to track individual pieces of equipment and related 
data, as well as for all types of Configuration Management e.g. Service Activation applications, as a provisioning 
interface for frequent configuration activities that require automation. 

Performance monitoring (PM) information is made available through the Performance Data IRP. 

It is realised that the alarm IRP, performance data IRP, and configuration service IRP all have similar needs to use 
notifications. The corresponding service is formalised as a Notification IRP. It specifies: firstly, an interface through 
which subscriptions to different types of notifications can be set up (or cancelled), and secondly, common attributes 
among all notifications. 

Further, applying a common Name Convention for Managed Objects is useful for co-operating applications that require 
identical interpretation of names assigned to network resources under management. 



10.4 Defining the IRPs 



It is important to avoid dependency on one specific technology, as the technologies will change over time. Applications 
need to be future-proof; One fundamental principle for achieving this is to clearly separate information models from 
protocols for the external interfaces, where the information models are more important than the selection of protocols. 

Thus, the detailed IRP specifications are divided into two main parts, following the directives from TMF's SMART 
TMN: 

• Information models specified with an implementation neutral modelling language. The Unified Modelling language 
(UML) has been selected, as it is standardised (by OMG), supported by most object oriented tools and used in 
several ongoing standardisation efforts (CIM, etc.) 

• Solution sets, i.e. mappings of the information models to one or several protocols (CORBA/IDL, SNMP/SMI, 
CMIP/GDMO, COM/IDL, etc.). Different protocol selections may be done for different IRPs. 
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Alarm IRP: information model 



- Alarm reporting parameters consistent wilh mj-T M.3100, X.721 , X.733, X.736 
and ETSI GSM 12.11 standards, and UMTS-speeific probable causes (Text) 

- Operations possible over the Alarm IRP (UMIVText) 
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Figure 12: IRP example 



1 1 Implementation aspects 
11.1 Layering of the OS applications 

UMTS operators might categories and organise its operation systems in many different ways as: 

A national fault and performance OS 

A national charging, billing and accounting OS 

Regional configuration OS 

Regional fault, performance and configuration OS 

etc 

This geographical dependent categorisation may change after time and the growth of the network. A physical 
architecture based on an open system design and re-usable application components would ease the work to adopt such 
structural changes. A management system build for a UMTS must provide the possibility of layering the applications. 



12 TMN planning and design considerations 

A TMN should be designed such that it has the capability to interface with several types of communications paths to 
ensure that a framework is provided which is flexible enough to allow for the most efficient communications: 

Between one NE and other elements within the TMN; 

Between a WS and other elements within the TMN; 

Between elements within the TMN; 

- Between TMNs. 

The basis for choosing the appropriate interfaces, however, should be the functions performed by the elements between 
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which appropriate communications are performed. The interface requirements are specified in terms of function 
attributes needed to provide the most efficient interface. 

12.1 Function attributes 

a) Reliability - The capabiHty of the interface to ensure that data and control are transferred such that integrity and 
security are maintained. 

b) Frequency - How often data is transferred across the interface boundary ( Normal behaviour ) 

c) Quantity - The amount of data that is transferred across the interface during any transaction. 

d) Priority - Indicates precedence to be given to data in case of competition for network resources with other 
functions. 

e) Availability - Determines the use of redundancy in the design of the communications channels between 
interfacing elements. 

f) Delay - Identifies the amount of buffering that may be tolerable between interfacing elements. This also impacts 
communications channel designs. 

Table 1 suggests a table of possible ranges for these function attributes. 

Table 1 : Possible ranges for TMN function attributes [1] 



Attributes 


Requirements 


Nature of attributes 


Performance or grade of service (P) 


Delay (speed) 


Short 

Medium 

Long 


Objective of design and control 
(acceptable/unacceptable but 
available/unavailable) 


Reliability 
(accuracy) 


High 

Medium 

Low 


Availability 


High 

Medium 

Low 


Characteristics of TMN traffic (C) 


Quantity 


Large 

Medium 

Small 


Condition or parameter of design 


Frequency 


Often continuous 

Periodic 

Sparse 


Priority 


High 

Medium 

Low 



12.2 Functional characteristics 

Each major type of telecommunications equipment has functional characteristic needs that can be used to describe the 
complexity of the interface. 

There are, however, a basic group of TMN application functions that cross all major types of telecommunications 
equipment. There are also unique TMN application functions that are performed by specific categories of major 
telecommunications equipment. Alarm surveillance is an example of the former, whereas billing information collection 
is an example of the latter. 

Functional characteristics of the elements within a TMN, e.g. OS, DCN and MD also describe the complexity of 
interfaces between these elements. 

12.3 Critical attributes 

Attribute values for a given function are generally consistent across the network elements. 
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When considering a single interface, it is important to identify the controlling attribute ranges for the design of the 
interface. 

If there are conflicting attribute values for different functions in a given network element, more than one instance of an 
interface may be needed. 

Overall TMN attribute values for the interfacing of elements within the TMN depend on the type and number of 
functions performed within these elements. In this case the functions are not consistent across TMN elements, but are 
controlled by the individual TMN design of an Administration. 

12.4 Protocol selection 

In many cases, more than one protocol suite will meet the requirements for the network element or TMN element under 
consideration. It is the approach for the 3GPP Telecom management standardisation to concentrate on protocol 
independent information models, allowing the mapping to several protocol suites. 

The rational behind this is: 

The blurring of Information and Telecommunication technologies in UMTS, it is required to work on a more 
open approach (acknowledging the market status and foreseen evolutions) 

The life-cycle of information flows is 10 to 20 years, while the protocols is 5 to 10 years 

The developments on automatic conversion allows for a more pragmatic and open approach 

The choice of the individual protocol from the recommended family will be left open to the vendors and operators. 

To provide the most efficient interface care should be taken to select the protocol suite that optimizes the relationship 
between the total cost to implement that protocol suite, the functional attributes and the data communications channels 
that carry the information across the interface. 

12.5 Communications considerations 

DCN architectures must be planned and designed to ensure that their implementation provides appropriate degrees of 
availability and network delay while minimizing cost. 

One must consider the selection of communications architectures, e.g. star, multipoint, loop, tree. 

The communications channels, e.g. dedicated lines, circuit-switched networks and packet networks used in providing 
the communications paths, also play an important role. 



1 3 IVIediation/lntegration 



The increase in the need to incorporate a hybrid set of technologies, multiple protocols and heterogeneous resources 
requires the availability of open management interfaces between the management systems and the different network 
resources. These interfaces require an underlying mechanism to mediate - interpret, translate, and handle data - between 
the various data representations and protocols. A set of Technology Integration Points [6] can be identified and will 
need to be supported. 

Software components on the open market as automatic conversion applications, gateways, mediation applications will 
be valuable products to fulfil the challenging task to incorporate multiple protocols and heterogeneous resources. 



£75/ 



(3G TS 32.102 version 3.0.0 Release 1999) 



29 



ETSI TS 132 102 V3.0.0 (2000-01) 



In the figure below are Technology Integration Points summarised for some technologies: 
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Figure 13: Technology Integration Points [21] 

Essentially, this figure indicates that from the technologies selected, three technology areas will need to be integrated. 
These are: 

Internet/Web based services; 

Object Request Broker (CORBA) based services; 

- Telecom based Manager/Agent services (i.e. CMIP/GDMO and SNMP/SMI). 

In order to provide adequate points of integration between these areas of technology, five Integration Points (IPs) have 
been identified - as outlined in the table and in text form below: 

Table 2: Technology Integration Points [21] 





Managed 

Objects 

(GDMO/SMI) 


Management 

Services 
(CMISE/SNMP) 


Java Objects 


Web Browser 
(HTTP/HTML) 


TMN Agent 


CORBA Objects 


IP1 




IP4 


IPS 




CORBA 
Services 




IP2 








TMN Manager 










IPS 


IP1 Provides mapping of objects defined in CORBA/IDL to managed objects defined in GDIVIO or SIVII. 

IP2 Provides mapping of appropriate CORBA Services to CIVIIS and SNIVIP services. 

IPS Provides a mapping of Web Browser technology access to CORBA objects (for situations where this may be 
needed as an addition to/replacement of Browser access to a database). 

IP4 Provides a mapping between Java based objects and CORBA objects. 

IPS Provides a high level convenient programming interface for the rapid development of TMN based 

manager/agent interactions. It also provides a convenient point of integration if it is necessary to separate out 
the two sides of the manager/agent interface from the point of view of technology selection. For example, 
allowing the manager role to perhaps be supported in a Web-based environment, but giving a good point of 
integration with a TIVIN based agent. 
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Annex A: (Informative) 
Technology considerations 

A.1 TIVIN building blocks 

TMN functions can be implemented in a variety of physical configurations [M.3010]. The relationship of the functional 
blocks to physical equipment is shown in Table 3 which names the TMN building blocks according to the set of 
function blocks which each is allowed to contain. For each building block there is a function block which is 
characteristic of it and is mandatory for it to contain. There also exist other functions which are optional for the building 
blocks to contain. Table 3 does not imply any restriction of possible implementations, but defines those identified 
within this Recommendation. 

The subclauses below give the definitions for consideration in implementation schemes. 

A. 1 . 1 Operations System (OS) 

The OS is the system which performs OSFs. The OS may optionally provide MPs, QAFs and WSFs. 

A.1 .2 Mediation Device (MD) 

The MD is the device which performs MPs. The MD may also optionally provide OSPs, QAPs and WSPs. 
MDs can be implemented as hierarchies of cascaded devices. 

A. 1.3 Q Adaptor (QA) 

The QA is a device which connects NE-like or OS-like with non-TMN compatible interfaces (at m reference points) to 
Qx or Q3 interfaces. 

A.1 .4 Data Communication Network (DCN) 

The DCN is a communication network within a TMN which supports the DCP. The DCN represents an implementation 
of the OSI layers 1 to 3, which include any relevant ITU-T (formerly CCITT) or ISO standards for layers 1 to 3. The 
DCN provides no functionality at layers 4 to 7. 

The DCN may consist of a number of individual subnetwork(s) of differing types, interconnected together. Por 
example, the DCN may have a backbone subnetwork(s) that provides TMN-wide connectivity between a variety of 
subnetwork(s) providing local access to the DCN. The various types of subnetworks may include technology specific 
subnetwork(s) such as the SDH DCC. 



A.1 .5 Network Element (NE) 



The NE is comprised of telecommunication equipment (or groups/parts of telecommunication equipment) and support 
equipment or any item or groups of items considered belonging to the telecommunications environment that performs 
NEPs. The NE may optionally contain any of the other TMN function blocks according to its implementation 
requirements. The NE has one or more standard Q-type interfaces and may optionally have P and X interfaces. 

Existing NE-like equipment that does not possess a TMN standard interface will gain access to the TMN via a Q 
Adaptor Function, which will provide the necessary functionality to convert between a non-standard and standard 
management interface. 
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A. 1.6 Workstation (WS) 



The WS is the system which performs WSFs. The workstation functions translate information at the f reference point to 
a displayable format at the g reference point, and vice versa. 

If equipment incorporates other TMN functionality as well as the WSF, then it is named by one of the other names in 
Table 3. 

Table 3. Relationship of TMN building block names to TMN function blocks 



(Notes 2 & 3) 


NEF 


MF 


QAF 


OSF 


WSF 


NE 


M 













(Note 3) 


MD 




M 











QA 






M 






OS 










M 





WS 










M 


M Mandatory 

Optional 
NOTES 

1 Within this table, where more than one name is possible, the choice on the 
building block name is determined by the predominant usage of the block. 

2 TMN building blocks may contain additional functionality which allows them to be 
managed. 

3 For the WSF to be present either the MF or OSF must also be present. This 
means that the WSF must address an OSF or a MF. The local man-machine 
access is not considered part of the TMN. 
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A.2 TMN standard interfaces 




T0404050-93/CI31 



Figure 14. Examples of interfaces for the TIVIN physical architecture M.3010 

Figure 12 shows the interconnection of the various TMN building blocks by a set of standard interoperable interfaces. 
The allowable interconnections of these standard interfaces within a given TMN may be controlled by both the actual 
interfaces provided and/or by security and routing restrictions provided within the various building block entities 
(e.g. passwords, log-ons, DCN routing assignment, etc.). 

TMN standard interfaces are defined corresponding to the reference points. They are applied at these reference points 
when external physical connections to them are required. 

There is a family of protocol suites for each of the TMN interfaces; Q3, Qx, X and F. The choice of the protocol is 
dependent on the implementation requirements of the physical configuration. 

A.2.1 Q interface 

The Q interface is applied at q reference points. 

To provide flexibility of implementation, the class of Q interfaces is made up of the following subclasses: 

the interface Q3 is applied at the q3 reference point; 

- the interface Qx is applied at the qx reference point. 

The Q3 interface is characterized by that portion of the information model shared between the OS and those TMN 
elements to which it directly interfaces. 

The qx reference point represents the requirements derived from the interaction between MF-MAF and other applicable 
MAFs. The difference in these requirements from those which a q3 reference point represents will be clarified using 
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TMN management functions (as defined in Recommendation M.3400 [5]) as well as some definite interface 
characteristics. The difference between Qx and Q3 interfaces are for further study. The Qx interface is characterized by 
that portion of the information model that is shared between the MD and those NEs and QAs it supports. 

The information models for both types of interfaces can potentially be the same but it can normally be expected that the 
less functionality there is, that the protocol supports, the less generic the information model will be. Hence, the MF is 
needed to provide conversion between the information models. 

Qx support non standardised protocols. 

A.2.2 F interface 

The F interface is applied at f reference points. The F interfaces connecting workstations to the TMN building blocks 
containing OSFs or MFs through a data communication network are included in this Recommendation. Connections of 
implementation specific, WS-like entities to OSs or NEs, are not subject of this Recommendation. 

A.2.3 X interface 

The X interface is applied at the x reference point. It will be used to interconnect two TMNs or to interconnect a TMN 
with other network or systems which accommodates a TMN-like interface. As such, this interface may require 
increased security over the level which is required by a Q-type interface. It will therefore be necessary that aspects of 
security are addressed at the time of agreement between associations, e.g. passwords and access capabilities. 

The information model at the X interface will set the limits on the access available from outside the TMN. The set of 
capabilities made available at the X interface for access to the TMN will be referred to as TMN Access. 

Additional protocol requirements may be required to introduce the level of security, non-repudiation, etc. which is 
required. 

Relationship of TMN interfaces to TMN building blocks 

Table 4 defines the possible interfaces which each named TMN building block can support. It is based upon the 
function blocks which Table 3 associates with each building block and the reference points between function blocks. 

Table 4: Relationship of TMN interfaces to TMN building blocks 







Qx 


Q3 


X 


F 


NE 


(Note1) 






OS 


(Note1) 






MD 


(Notel) 









QA 


(Note 1 ) 







WS 








(Note 2) 
M 


M 


NOTE 1 : 
NOTE 2: 


Mandatory 
Optional 

At least one of the interfaces inside the box must be present. 
This mandatory relationship only to workstations. 
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Table 5: Differences between TIVIN interfaces [1] 



Differentiating factors 


X Interface 


F interface 


Q3 Interface 


Function blocks 


OSF- OSF 


OSF-WSF 
MF-WSF 


OSF-NEF/ 
OSF - MF/ 
OSF - OSF/ 
OSF - OAF 


Service type 


interactive (object 
oriented)/store and forward 
file transfer/ 


interactive (object oriented) 


interactive (object 
oriented)/file transfer 


Syntax 


machine/macliine 
ASN.1 


macliine/machine 

liuman/machine 

cliaracters 


machine/machine ASN.1 


Access control 
requirement on an activity 
basis 


IVIandatory 


optional 


optional 


Other security aspects 
(e.g. data integrity/ 
encryption) 


Yes 


yes 


For further study 


NOTE: Ox interface is for furti 


ler study. 







The application layer (layer 7) of each family is common, and is the basis for ensuring interoperability. Some 
functionality of layer 7 may not always be required (e.g. file transfer). In certain interfaces, some or all of the other 
layers may have reduced functionality. 

The requirement of the lower layers is to support the upper layers. Several network types have been identified as 
suitable for the transport of TMN messages such as those detailed in Recommendation Q.8 1 1 [3] . Any one or a mixture 
of networks could be used so long as suitable interworking is made available. 

For network equipment that does not have an interoperable interface, there is a need to convert the protocols and 
messages into an interoperable interface format. This conversion is performed by Message Communications Functions 
plus Q Adaptor Functions which can reside in Q Adaptors, Network Elements, Mediation Devices or Operations 

Systems. 



£75/ 



(3G TS 32.102 version 3.0.0 Release 1999) 



35 



ETSI TS 132 102 V3.0.0 (2000-01) 



Annex B (informative): 
Change history 



This annex lists all change requests approved for this document since the specification was first approved by 3GPP 
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